Subject: Updated Multicast Proposal (part 1)

From: Paul Brittain <[email-masked]>
Date: Thu, 21 Mar 96 05:05:00 GMT

DLSw Multicast Protocols                                  16
David Bryant3Com Corp                     October 1995
Mike Redden Proteon Inc

            DLSw Multicast Protocol Enhancements

1. BACKGROUND                                              2
2. INTENT                                                  2
3. SCOPE                                                   2
4. OVERVIEW                                                4
5. CAPABILITIES EXCHANGE                                   5
6. MULTICAST GROUPS AND ADDRESSING                         5
6.1 USING MULTICAST GROUPS                                 6
 6.1.1 SNA CLIENT/SERVER GROUPS                           6
 6.1.2 NETBIOS GROUPS                                     7
 6.1.3 MIXED GROUPS                                       7
7. DLSW MESSAGE TRANSPORTS                                 7
7.1 TCP/IP CONNECTIONS                                     7
7.2 UDP DATAGRAMS                                          7
7.3 MULTICAST DATAGRAMS                                    8
8. SNA SUPPORT                                             8
8.1 ADDRESS RESOLUTION                                     8
8.2 CIRCUIT SETUP                                          9
8.3 MULTICAST RELIABILITY                                  9
 8.3.1 RETRIES                                            9
9. NETBIOS                                                10
9.1 NETBIOS REMOTE NAME DIRECTORY SUPPORT                 11
9.2 ADDRESS RESOLUTION                                    11
9.3 CIRCUIT SETUP                                         12
9.4 MULTICAST RELIABILITY AND RETRIES                     12
10. SEQUENCING                                            12
11. MIGRATION                                             13
11.1 CONNECTING TO DOWNLEVEL NODES                        13
11.2 COMMUNICATING WITH DOWNLEVEL NODES                   13
12. SSP FRAME FORMATS                                     14
12.1 MULTICAST CAPABILITIES CONTROL VECTOR                14
12.2 MULTICAST PACKETS                                    14
12.3 UDP PACKETS                                          15

1.Background

RFC 1795 specifies an AIW standard for the Switch to Switch
Protocol (SSP) of Data Link Switching (DLSw).   Through
implementation and installation experiences, vendors have
become increasingly more concerned with the scalability of
the DLSw protocols in large networking situations.
Accordingly, a DLSw Scalability group has been established
within the AIW to define a set of DLSw protocol enhancements
for the purpose of improving DLSw scalability.

It is assumed that the reader is familiar with DLSw and RFC
1795.  No effort has been made to explain those protocols or
associated terminology.  Note: Throughout this document the
acronym SSP has been used interchangeably to refer to both
the "switch to switch protocol" of DLSw and the set of state
machines which implement the protocol.  However, the
endpoint of an SSP message exchange is referred to as a
DLSw.

2.Intent

This document defines a set of SSP protocol enhancements to
RFC 1795 which will improve the scalability of DLSw.  These
enhancements are designed to be fully backward compatible
with existing  RFC 1795 implementations.   Once completed
and approved within the AIW, it is the intent of the DLSw
Scalability group  to submit these enhancements to the IETF
in the form of an informational RFC.  As a compatible set of
enhancements to RFC 1795, this document does not replace or
supersede RFC 1795.

3.Scope

The DLSw Scalability group of the AIW has identified a
number of scalability issues associated with existing DLSw
protocols as defined in RFC 1795:

u Administration

  RFC 1795 implies the need to define the transport address
  of all peer DLSws at each DLSw.  In highly meshed
  situations (such as those often found in NetBIOS
  networks), the resultant administrative burden is
  undesirable.

u Address Resolution

  RFC 1795 defines point to point TCP (or other reliable
  transport protocol) connections between each DLSw.  When
  attempting to discover the location of an unknown
  resource, a DLSwsends an address resolution packet to
  each partner DLSw over these connections.  In highly
  meshed configurations, this can result in a very large
  number of packets in the transport network.  Although
  each packet is sent individually to each DLSw partner,
  they are each identical in nature.  Thus the transport
  network is burdened with excessive numbers of identical
  packets.  Since the transport network is most commonly a
  wide area network where bandwidth is considered a
  precious resource, this packet duplication is
  undesirable.

u Broadcast Packets

  In addition to the address resolution packets described
  above, RFC 1795 also propagates NetBIOS broadcast packets
  into the transport network.  The UI frames of NetBIOS are
  sent as LAN broadcast packets and RFC 1795  DLSws
  propagate these packets over the point to point transport
  connections to each DLSw partner.  In the same manner as
  above, this creates a large number of identical packets
  in the transport network.  This is also considered
  undesirable.  And because NetBIOS UI frames can be sent
  by applications, it is difficult to predict or control
  the rate and quantity of such traffic.   This compounds
  the undesirability of the existing RFC 1795 propagation
  method for these packets.

u TCP (transport connection) Overhead

  As defined in RFC 1795, each DLSw maintains a transport
  connection to its peer DLSw partners.  Each transport
  connection guarantees in order packet  delivery.   This
  is accomplished using acknowledgment and sequencing
  algorithms which require both CPU and memory at the DLSw
  endpoints in direct proportion to the number transport
  connections.   The DLSw Scalability group has identified
  two scenarios where the number of transport connections
  can become significant resulting in excessive overhead
  and corresponding equipment costs (in memory and CPU).
  The first scenario is found in highly meshed DLSw
  configurations where the number of transport connections
  approximates n2 (where n is the number of DLSws).  This
  is typically found in DLSw networks supporting NetBIOS.
  The second scenario is found  in networks  where many
  remote locations communicate to few central sites.
  In this case, the central sites must support n transport
  connections  (where n is the number of remote sites).
  In both scenarios the resultant transport connection
  overhead is considered undesirable depending upon the
  value of n.

u LLC2 overhead

  RFC 1795 specifies that each DLSw provides local
  termination for the LLC2 (SDLC or other SNA reliable data
  link  protocol) sessions traversing the SSP.   Because
  these reliable data links also provide guaranteed in
  order packet delivery, the memory and CPU overhead of
  maintaining these connections can also become
  significant.   This is particularly undesirable in the
  second scenario described above.  This is because the
  number of reliable connections maintained at the central
  site is the aggregate of the connections maintained at
  each remote site.

It is not the intent of this document to address all the
undesirable scalability issues associated with RFC 1795.
This paper identifies protocol enhancements to RFC 1795
using the inherent multicast capabilities of the underlying
transport network to improve the scalability of RFC 1795.
It is believed that the enhancements defined will address
many of the issues identified such as: administration,
address resolution,  broadcast packets, and to a lesser
extent transport overhead.   This paper will not address
LLC2 overhead.   Subsequent efforts by the AIW and/or DLSw
Scalability group may address the unresolved scalability
issues.

In addition, it is recognized that not all transport
protocols applicable to DLSw will provide multicast
services.  Since TCP is the most prevalent transport
protocol in use today, the DLSw Scalability group has chosen
to focus its definition around TCP based multicast services
and address any other protocols as the need may arise in the
future. This proposal does not consider the impacts of IPv6
as this was considered too far from widespread use at the
time of writing.

4.Overview

This paper will describe the use of multicast services
within the transport network to improve the scalability of
DLSw based networking.   There are only a few main
components of this proposal:

u Single session TCP connections

  RFC 1795 defines a negotiation protocol for DLSws to use
  either two unidirectional or one bi-directional TCP
  connection.    DLSws implementing these enhancements must
  support the use of one bi-directional TCP connection.
  Negotiation to two unidirectional TCP connections is only
  supported for migration purposes when communicating with
  DLSws that do not implement these enhancements.

  Editors Note:  I believe the suggested syste for this was
  as follows.  When bringing up a bidirectional pipe, a
  DLSw must first bring up 2 unidirectional pipes as in
  RFC1795, then, if both DLSw partners support negotiation
  to a single TCP pipe, the partner with the numerically
  lower IP address should drop the pipe that it opened to
  the other partner.

u TCP connections on demand

  DLSws will only establish a TCP connection when
  necessary.  SSP connections to DLSws which do not
  implement this enhancement are assumed to be established
  by means defined outside this paper.  DLSws implementing
  this enhancement utilize multicast services to send
  address resolution packets (CANUREACH_ex, NETBIOS_NQ_ex,
  etc.).  If a positive response is received, then a TCP
  connection is only established to the associated DLSw
  peer if one does not already exist.  Correspondingly, TCP
  connections are brought down when there are no circuits
  to a partner DLSw for an implementation defined period of
  time.

u Address resolution through multicast and UDP

  As described above, multicast services in the transport
  network are used to propagate address resolution packets.
  This avoids the need to maintain TCP SSP connections
  between when no circuits are active.  In addition, most
  multicast services (including TCP's MOSPF, DVMRP, MIP,
  etc.) replicate and propagate messages only as necessary
  to deliver to all multicast members.   This avoids
  duplication and excessive bandwidth consumption in the
  transport network.

  To further optimize the use of WAN resources, address
  resolution responses are sent in a directed fashion via
  UDP transport.   This avoids the need to setup or
  maintain TCP connections when they are not required.  It
  also avoids the bandwidth costs associated with
  broadcasting.

  It is also permitted to send some address resolution
  traffic over existing TCP connections.  The conditions
  under which this is permitted are detailed in section
  8.2.

  Note:  There is some concern that the use of UDP adds a
  20-byte header to multicast traffic that adds nothing to
  the function of this proposal.  An alternative would be
  to obtain a new IP protocol ID for DLSw v2 and to access
  IP multicast/unicast facilities direct.  Proposals are
  invited on this topic.

u NetBIOS broadcasts over multicast and UDP

  In the same manner as above, NetBIOS broadcast packets
  (as defined by  the broadcast bit in the routing
  information field) are sent over the transport multicast
  services.  This avoids the need to establish TCP
  connections between DLSws when there are no circuits
  required.   In addition, bandwidth in the transport
  network is conserved by utilizing the efficiencies
  inherent to multicast service implementation.

5.Capabilities Exchange

In order to guarantee both backward and forward capability,
DLSws which implement multicast enhancements will carry a
"Multicast Capabilities" Control Vector in their
capabilities exchange.   Presence of the Multicast
Capabilities control vector indicates support for the
protocols defined in this document.  Conversely, lack of the
Multicast Capabilities control vector indicates no support
for these extensions.

The Multicast Capabilities control vector contains the
following fields:

u Version Number

  A one byte binary numeric identifier of the Multicast
  support capabilities.   Implementations corresponding to
  this specification will carry a binary value of  x'01'.

6.Multicast Groups and Addressing

In order to accommodate logical network separation, multiple
multicast address groups are allowed.   To further optimize
address resolution protocols, multicast groups can be
defined in two ways: Client/Server and Peer to Peer.   There
are 64 client/server multicast groups and 127 peer to peer
multicast groups.  Roughly speaking the two multicast group
types correspond to the two predominant network
configurations represented by SNA and NetBIOS.   SNA
networks are largely Client/Server oriented in that many
remote sites (clients) require access to a small number of
central sites (servers).  But direct communications between
remote sites (client to client) is far less likely.
NetBIOS networks are largely peer to peer in that NetBIOS
protocols require the participation of all NetBIOS nodes in
many of the protocol exchanges (e.g., ADD_NAME_QUERY, etc.).

Peer to Peer multicast groups are defined by shared use of a
single multicast address.  All members of the peer to peer
group send and receive packets to/from the same multicast
address.   An individual DLSw can be a member of multiple
peer to peer (and/or client-server groups) at the same time.
Peer to Peer multicast group addresses range from
254.0.1.129 to 254.0.1.255.

Client/Server groups are defined by shared use of two
multicast addresses.  Clients within a group are addressed
by one multicast address and servers are addressed by the
other.   In this way communications can be targeted to
either clients or servers.   The Client/Server address range
is from 254.0.1.1 to 254.0.1.128.   Within a given
Client/Server multicast group the address of the client and
the server are offset  by 64.   The server address is always
64 higher than the client address.  To illustrate:  clients
in Client/Server multicast group 1 will have an address of
254.0.1.1 and servers will have an address of 254.0.1.65.
Clients in multicast address group 2 will have an address of
254.0.1.2 and servers 254.0.1.66, and so on up to
Client/Server group 64 where clients have address 254.0.1.64
and servers have address 254.0.1.128.

6.1  Using Multicast Groups

The multicast addressing as described above can be
effectively used to limit the amount of broadcast/multicast
traffic in the network.  It is not the intent of this
document to describe how individual DLSw/SSP implementations
would assign or chose group addresses.   In particular, this
document does not attempt to define an algorithm for
searching a multi-level hierarchy of DLSw nodes.

The specifics of how nodes are grouped, and how searching is
done and exposed to the end user is an issue for the
specific implementor.    In order to clarify the concepts,
however, a few examples are provided below:

6.1.1  SNA Client/Server groups

In the typical SNA Subarea configuration communications is
typically between PU2 and Host sites.  That is to say,
communications is not sent directly between PU2 locations.
In this scenario, it would be useful for DLSws to be
assigned a single group number and a client or server
designation.  Host sites would be designated as servers and
PU2 sites as clients.  When a test frame is received at a
client site, it would send out a CANUREACH_ex to the server
multicast address associated with that group.  This
effectively avoids searching the other PU2 sites for the
host.  In the same way, test frames generated at the host
site would result in a CANUREACH_ex message being sent to
the client multicast address of the group.  This avoids
searching other host sites for the PU2.

6.1.2  NetBIOS groups

Large interconnected NetBIOS networks can be separated into
multiple logical and distinct networks through the use of
different multicast group numbers.  A set of NetBIOS
stations/locations in one network can be assigned one group
number and a different set a different group number.  This
effectively separates the two networks because address
resolution packets will never flow from one network to the
other.

It's expected that normally peer group addresses would be
used for NetBIOS because many of the NetBIOS UI frames must
be broadcast to all NetBIOS stations in the network
regardless of application specifics (e.g., ADD_NAME_QUERY,
ADD_GROUP_QUERY, etc.).   It is possible, however, to
utilize the Client/Server addressing mechanisms to
specifically target NAME_QUERY flows only to certain
locations where NetBIOS servers are known to be located.
This provides an function much like filtering.

6.1.3  Mixed Groups

In many scenarios, DLSws will be connected to LANs which
have both SNA and NetBIOS traffic.  In this case DLSw
implementations will likely need fairly sophisticated means
of assigning multicast groups.
One simple mechanism might be to assign group numbers
(and/or Client-Server roles) via protocol.  For example.
SNA is Client/Server group 1 and this location is a client
location.  NetBIOS is Peer to Peer group 129.  The DLSw can
then effectively use the SAP portion of received frames when
selecting the appropriate multicast address.

When further granularity is desirable, more complicated
mechanisms would be required.  For example, if a given DLSw
is connected to a LAN with both PU2 and T2.1 nodes, both
Client/Server and Peer to Peer communications is possible.
In this case, it may be possible for a DLSw to distinguish
between groups by associating multicast groups to individual
nodes via MAC address (or equivalent).